[% setvar title The Perl 6 Summary for the week ending 20030330 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030330'></a><h1>The Perl 6 Summary for the week ending 20030330</h1>
<p>Welcome once again to the gallimaufry that is a Perl 6
summary. Unfettered this week by the presence of feline distraction
we plunge straight into the crystal clear waters of perk6-internals.</p>
<a name='Iterator proof of concept'></a><h2>Iterator proof of concept</h2>
<p>People must really like Leo T&ouml;tsch's Iterator proposal and
patch. There was only one comment about it this week (from Leo, so
I'm not sure if it counts) asking for thoughts about a possible Ref or
Reference class. Anyone?</p>
<p><a href='http://groups.google.com/groups?threadm=3E7ED9AF.904@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Bonsai'></a><h2>Bonsai</h2>
<p>Zach Lipton announced that he has Bonsai up and running on the Parrot
CVS repository. This gives us a shiny new way of looking at the
history of the distribution. Thanks Zach.</p>
<p><a href='http://tinderbox.perl.org/bonsai' target='_blank'>tinderbox.perl.org</a></p>
<a name='BASIC, IMCC and Windows'></a><h2>BASIC, IMCC and Windows</h2>
<p>Clinton A Pierce had problems trying to get IMCC building correctly
under Win32 in order to generate a binary distribution for the win32
platform. He finally brought up a working IMCC on Friday and asked for
comments about what a binary distribution should look like.</p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030326162310.01dab620@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030328092715.029084b0@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<a name='getopt.macro'></a><h2>getopt.macro</h2>
<p>Inspired by the argument processing in Leon Brocard's uniq(1)
implementation, Jonathan Scott Duff presented a getopt macro for
Parrot programmers. Benjamin Goldberg had a few suggestions about how
to make things a little more flexible.</p>
<p><a href='http://groups.google.com/groups?threadm=20030327132923.B16979@cbi.tamucc.edu' target='_blank'>groups.google.com</a></p>
<a name='Patch to examples/assembly/cat.pasm'></a><h2>Patch to <b><i>examples/assembly/cat.pasm</i></b></h2>
<p>Paul Duncan offered a patch to <b><i>examples/assembly/cat.pasm</i></b> which
would cause it to terminate when it received a ctrl-D.</p>
<p><a href='http://groups.google.com/groups?threadm=20030327235825.GH27611@ns.snowman.net' target='_blank'>groups.google.com</a></p>
<a name='IMCC and scientific notation'></a><h2>IMCC and scientific notation</h2>
<p>Having got IMCC working in a win32 environment, Clinton A Pierce
discovered that IMCC didn't understand scientific notation, but the
parrot assembler does. Leo T&ouml;tsch pointed out that it sort of
does, but instead of <code>1e20</code> you have to write <code>1.e20</code>. Joseph Ryan
wondered if handling scientific notation wasn't really a job for
individual compilers, but Clint and Mark Biggar explained why this
wasn't a good idea. As Mark said, in a world with BigFloats you don't
want to have to expand 1e2048 into a 2049 character string if you can
possibly help it.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-21729-54213.8.88208842817178@bugs6.perl.org' target='_blank'>groups.google.com</a></p>
<pre>=head RT spam</pre>
<p>Someone claiming to be Marla Hurley crawled out from under a stone and
took it upon themselves to offer credit to the perl6 RT
installation. Thanks. We needed that.</p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>The language list was again busier than the internals list this week,
but volume has fallen on both lists. (If you don't count an off topic
thread on the internals list, which I haven't, there were only 22
messages there this week. And very few patches from Leopold
T&ouml;tsch, I hope he's all right.)</p>
<a name='is static?'></a><h2>is static?</h2>
<p>Discussion of static/state variables continued. Arcadi Shehter
wondered if it made sense to attach <code>but</code> properties to closures. I
confess I didn't really understand what he was driving at. Austin
Hastings and Larry saw something in it, and the question shifted to
ways of doing state variable initialization, which in turn led to
possible changes in the various control of flow keywords. As Larry
pointed out, if you have a static variable:</p>
<pre>   state $variable</pre>
<p>Then, assuming that you need 'undef' to be a possible value for your
variable, you need some way of doing once and only one initialization
of that variable.</p>
<pre>
   state $variable;
   ONCE_AND_ONLY_ONCE { $variable = $initial_value };</pre>
<p>The problem is that INIT and CHECK blocks happen too early; in the
code above, <code>$initial_value</code> may well not be set, if your state
variable is set up inside a closure this becomes even more
likely. Larry reckons that the most useful initialization semantics
appear to be 'just in time'. In other words you want initialization to
happen on the first actual call to a closure. But <code>FIRST {...}</code> is
already taken, so Larry is considering renaming FIRST and LAST to
ENTER and LEAVE, freeing up FIRST to mean &quot;my very first
time&quot;. Freudian analysis was discouraged.</p>
<p><a href='http://groups.google.com/groups?threadm=15998.63434.790251.478232@gargle.gargle.HOWL' target='_blank'>groups.google.com</a></p>
<a name='Argument initializations'></a><h2>Argument initializations</h2>
<p>Michael Lazzaro summarized the various different and proposed
assignment operators available in Perl 6, including a proposed <code>::=</code>
for 'only assign to uninitialized variables'. Michael wondered how
these could be used in method signatures and proposed some changes to
the signature system as set out in Apocalypse 6. People were dubious
about this, with Damian saying &quot;I don't think that allowing 20
different types of assignment in the parameter list of a subroutine
actually helps at all.&quot; I'm not sure Michael is convinced yet.</p>
<p><a href='http://groups.google.com/groups?threadm=8E178DC3-5EF1-11D7-BB31-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='P6ML?'></a><h2>P6ML?</h2>
<p>Michael Lazzaro asked if anyone was actually working on P6ML (a
project name that popped up last week in the 'XML is too hard for
Programmers' thread) and if there was any idea of what such a project
would entail. Robin Berjon was unsure of the wisdom of such a project,
arguing that supporting a tool that wasn't strict about the XML it
parsed would be a retrograde step and giving reasons as to
why. However, he did think that creating a toolset for 'recuperating
data from a quasi-XML [document] (aka tag soup)' would be interesting
and useful, and he proposed a couple of approaches.</p>
<p>It's apparent, from reading this thread that people who don't like the
current generations of XML tools really don't like them at all:
adjectives such as 'craptacular' and phrases like 'festering pile of
steaming camel turds' were bandied about. Then there's the 'Perl has
lots of ways of doing XML, which is great because you can pick the one
that suits you' camp, and the 'Perl has lots of ways of doing XML,
which is terrible because you have to pick the one that suits you and
that takes time' camp.</p>
<p>Leon Brocard pointed out that, whilst Perl 6 might have nicer syntax
and a faster parsing engine, there was nothing to stop people working
out, and implementing, the required semantics in Perl 5 right
now. There was a fair amount of muttering that, however desirable or
otherwise P6ML may be, there wasn't really much need to be discussing
it on a language design list (as if that could stop anything).</p>
<p>Dan Sugalski caught everyone out by raving about the idea: &quot;the
thought of altering Perl 6's grammar to make it a functional language
is sheer genius [...] I say we start right away!&quot;. The only catch is
that Dan was talking about ML, a programming language and he bent the
needle on Austin Hasting's Sarcasmeter. But he promised to fix any
such devices at OSCON if their owners would bring them to him
there. So that's all right then.</p>
<p><a href='http://groups.google.com/groups?threadm=D53FA5D4-5EF1-11D7-BB31-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Summary writer goes all red and glowy.'></a><h2>Summary writer goes all red and glowy.</h2>
<p>Matthijs van Duin pointed out that Piers had misspelled him as
'Mattijs' 4 times in last week's summary.</p>
<p>I am really sorry and I shall endeavour never to do it again.</p>
<a name='Support for attributed DAGs'></a><h2>Support for attributed DAGs</h2>
<p>In a thread deceptively named 'Perl and *ML', Dan opined that XML
would be so much easier to support if Perl had good support for
attributed DAGs (That's Directed Acyclic Graphs, or 'trees'), and
noted that having such support would be good for things like Abstract
Syntax Trees too. Robin Berjon wasn't so sure, pointing out that,
whilst fast and efficient graph support would be really useful,
acyclic graphs weren't that useful for XML as useful XML
representations usually had back links to parent and sibling nodes
(and that's before you take linking into account). I have the feeling
that further discussion of graph support probably belongs on the
internals list for the time being, but I could well be wrong.</p>
<p><a href='http://groups.google.com/groups?threadm=a05210603baa7749a319f@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>I've already apologized to Matthijs &quot;Mattijs&quot; van Duin for misspelling
his name, but I'll do it again. I'm really, really sorry.</p>
<p>If you've appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or an ArtixScan 2500f to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, photographic and writing commissions, or
an ArtixScan 2500f to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
<p>This week's summary was again sponsored by Darren Duncan. Thanks
Darren. If you'd like to become a summary sponsor, drop me a line at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>.</p>
</div>
